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Objectives: The ability to support healthcare document sharing is imperative in a health information exchange (HIE). Shar- 
ing imaging documents or images, however, can be challenging, especially when they are stored in a picture archiving and 
communication system (PACS) archive that does not support document sharing via standard HIE protocols. This research 
proposes a standard- compliant imaging gateway that enables connectivity between a legacy PACS and the entire HIE. Meth- 
ods: Investigation of the PACS solutions used at Gil Hospital was conducted. An imaging gateway application was then de- 
veloped using a Java technology stack. Imaging document sharing capability enabled by the gateway was tested by integrating 
it into Gil Hospital's order communication system and its HIE infrastructure. Results: The gateway can acquire radiology im- 
ages from a PACS storage system, provide and register the images to Gil Hospital's HIE for document sharing purposes, and 
make the images retrievable by a cross-enterprise document sharing document viewer. Conclusions: Development of an im- 
aging gateway that mediates communication between a PACS and an HIE can be considered a viable option when the PACS 
does not support the standard protocol for cross-enterprise document sharing for imaging. Furthermore, the availability of 
common HIE standards expedites the development and integration of the imaging gateway with an HIE. 
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I. Introduction 

Health information exchange (HIE) [1] enables the exchange 
and interoperability of healthcare data or information by 
allowing the secure and integrated sharing of information 
among numerous stakeholders to improve healthcare qual- 
ity and efficiency [2] . HIE facilitates the movement of clini- 
cal information between hospitals, laboratories, radiology 
centers, pharmacies, payers, public health departments, and 
other clinical providers. With the cross-organizational data 
exchange, clinicians can gather more information and thus 
provide better clinical diagnosis and treatment, which results 
in better patient care. 
Among the various types of clinical information that are 
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shared in HIE, we focused on the sharing of medical imag- 
ing documents. Imaging documents are generated by various 
technologies, such as computed tomography, positron emis- 
sion tomography, magnetic resonance imaging, ultrasound, 
X-ray radiography, biomagnetic, laser surface scan, and 
nuclear medicine. A picture archiving and communication 
system (PACS) [3,4] provides the mechanism to digitize and 
store the images acquired from imaging equipment or mo- 
dality, transmit the images over a network, and display the 
images for diagnosis or other medical use. PACS makes the 
use of radiology films obsolete and has been evolving over 
time to be the de facto medical imaging solution in hospitals 
and clinics. On the contrary, PACS implementation can vary 
among vendors. To provide a standard method especially in 
the transfer of medical images and the associated informa- 
tion over a network and across various PACS implementa- 
tions, the National Electrical Manufacturers Association as- 
sembled a committee tasked with publishing Digital Imaging 
and Communication in Medicine (DICOM) standards [5,6]. 
A PACS implementation that is compliant with the DICOM 
specifications shall be interoperable with other DICOM- 
compliant PACS solutions developed by other vendors. 

PACS enables the interconnection of medical imaging de- 
vices and applications via DICOM networking, a point-to- 
point network protocol that is based on TCP/IP. A PACS ap- 
plication is identified by an Application Entity (AE) title. It 
can communicate with another system in a DICOM network 
if the other party's AE title is also known and recognized as 
a legitimate peer. This requirement in practice constrains 
PACS use to the departmental level since imaging data can- 
not be easily shared with other departments without estab- 
lishing an exclusive point-to-point communication channel. 
On the other hand, however, the data stored in the PACS ar- 
chive are effectively insulated from public exposure and are 
thus protected from access by an unauthorized system. Tak- 
ing into account the needs for imaging data sharing in HIE, 
the consequence is twofold. First, an intermediary is needed 
to mediate secure imaging data sharing between a PACS and 
an HIE. Secondly, it is desirable to base the mediation on ex- 
isting standards or protocols so that a similar approach can 
be adopted in other similar environments, thus reducing the 
time to develop a tailored solution on a case-by-case basis. 

This report introduces the cross-enterprise document shar- 
ing for imaging (XDS-I) gateways developed for the purpose 
of integrating legacy PACS solutions installed at the Gil 
Hospital and its affiliate branches with an HIE that is also 
being tested across the hospital network. Emphasis is placed 
on building the gateway mediation capability by utilizing the 
healthcare interoperability standard published by the Inte- 
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grating Healthcare Enterprise (IHE) initiative. 

II. Case Description 

1. HIE Establishment at Gil Hospital 

Gachon University Gil Hospital (henceforth, Gil Hospital) 
operates six affiliate hospitals and is connected with several 
clinics. A community HIE is projected to be developed that 
will enable health data sharing across Gil Hospital, the af- 
filiate branches, and the clinics. Prior to rolling out a full- 
scale HIE, an early staging environment is created to test the 
functionalities of various HIE components. For the imaging 
document data sharing capability, three facilities are desig- 
nated to participate in the testing: Gil Hospital and two affili- 
ate branches identifiable as Dong-Incheon Gil Hospital and 
Namdong Gil Hospital. 
Each participating facility has PACS infrastructure installed 
and operated on a day-to-day basis. The operation of the 
PACS is managed independently by each facility. When a pa- 
tient is admitted to a facility for the first time, he/she should 
register his/her personal information. The patient credential 
is local, associated only with the facility where the registra- 
tion occurs. This signifies that patient information can be 
different in other facilities. Every time a patient is examined 
at a facility, the imaging data acquired from the modality 
equipment will then be stored in the PACS archive storage 
installed in the respective facility. The mechanism for image 
data retrieval from the PACS storage can differ for each fa- 
cility. A PACS solution in one facility, for example, provides 
image retrieval service via a non-DICOM standard interface 
and restricts DICOM Storage and Query/Retrieve services 
via DICOM networks. Therefore, it is important to address 
configurability and flexibility issues in the imaging gateway 
design so that it can be interfaced with a multitude of PACS 
solutions. 

Network connectivity with the server applications of the 
PACS solutions installed in all facilities can only be estab- 
lished via a DICOM network interface. None of the PACS 
server applications provides an alternative interface, for 
example the web interface referred to as Web Access to DI- 
COM Persistent Objects (WADO) has been specified in the 
DICOM standard. Having no alternative imaging data inter- 
face enforces heavyweight image retrieval by a display client 
since the image should be transported over the network in 
a DICOM file format. A binary in DICOM format can be 
large, on the order of megabytes, especially if it contains 
numerous image frames. This is problematic in the case of a 
slow network or when a preview of a multi-frame image is 
needed for display. Hence, it is also important for the imag- 
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ing gateway to provide an interface that can be configured to 
be accessible from an external network, while ensuring the 
security of the image transfer and taking care of the perfor- 
mance aspect of the transferrable image payload. 

Besides PACS, each participating facility also operates an 
order communication system (OCS). OCS is a computer 
application that is used to enter diagnostic and therapeutic 
patient care orders [7]. Like PACS, the OCS application is 
managed independently by each facility This reflects the ab- 
sence of information sharing between the OCS applications 
operated across the facilities. Interestingly, the Gil Hospital 
OCS was developed with additional functionalities that 
supplement the prescription input system. It can also handle 
orders for the medical image information system, remote 
service system, resource management system, and electronic 
medical card system [8]. It can be concluded that, in case of 
Gil Hospital, the OCS is the entry point to patient care and 
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Figure 1. Staging environment for PACS-HIE connectivity at Gil 
Hospital. PACS: picture archiving and communication 
system, HIE: health information exchange, OCS: order 
communication system. 



management continuum. 

An order for medical image examination is initially re- 
corded in the OCS. Subsequently, an examination will be 
performed using the respective medical equipment. The 
medical image will be stored by the PACS. Each medical im- 
age contains various types of metadata that are referenced 
to identify and describe the image. The PACS operator uses 
patient information provided by the OCS, including patient 
ID, patient name, patient gender, patient birthdate, and pa- 
tient demographics, when embedding patient- related meta- 
data into the image. Figure 1 shows a diagram of the staging 
environment for PACS-HIE connectivity. As shown in the 
picture, each of the affiliated hospitals operates PACS and 
OCS. In addition, Gil Hospital also manages a datacenter. All 
the facilities can be connected securely via a virtual private 
network (VPN). 

2. Imaging Gateway Development 

The imaging gateway has been developed as the imag- 
ing document sharing enabler in the Gil Hospital HIE 
infrastructure. On the HIE-facing facade of the gateway, it 
implements the document sharing for imaging workflow 
that is specified in IHE IT Infrastructure (IHE-ITI) and IHE 
Radiology Technical Frameworks (IHE-RAD TF) [9]. On 
the PACS-facing facade, several modules are developed to 
address the characteristics of PACS solutions operated in the 
environment while leaving enough flexibility to deploy the 
gateway in other types of setup. 

1) Cross-enterprise document sharing for imaging workflow 
Figure 2 illustrates the imaging document sharing workflow 
as specified in the IHE-RAD TF. As seen in the figure, imag- 
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Figure 2. Cross-enterprise document sharing (XDS) for imaging specified in the Integrating Healthcare Enterprise-Radiology (IHE-RAD) 
Technical Framework. MTOM: Message Transmission Optimization Mechanism, XOP: XML-binary Optimized Packaging. 
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ing document sharing involves several participating com- 
ponents, which are also referred to as "actors". The imaging 
document source is a component that provides imaging doc- 
uments to be shared into the HIE. The document repository 
is an actor that stores cross-enterprise documents ranging 
from text, hypertext, images, multimedia files, and so forth. 
The document registry maintains the metadata of the docu- 
ments that have been stored in the document repository. 
A document consumer retrieves an XDS document from 
HIE to be shown on a display interface. Specific to imaging 
documents, the retrieval is handled by an imaging document 
consumer. 

Based on the workflow in Figure 2, we implemented the 
gateway as follows. The imaging document source is the 
gateway that intermediates the legacy PACS with HIE. It is 
capable of providing and registering imaging documents to 
the document repository to be included in the shared docu- 
ment listings in the HIE. When providing and registering the 
images to the document repository, it utilizes the RAD-68 
transaction specification of the IHE-RAD TE In this trans- 
action, images are grouped into sets and only image mani- 
fests or references are registered to the document repository 
instead of the original DICOM images. Image manifests are 
embedded as an attachment to a SOAP request and then sent 
via HTTP to a SOAP Web service endpoint of the document 
repository that is responsible for receiving XDS document 
registration. The SOAP request body contains additional 
metadata whose format is specified in the RAD-68 transac- 
tion. Metadata values are populated by the imaging docu- 
ment source based on the content of the image manifest. 

After an image manifest file is provided and registered into 
the document repository, its metadata will then be regis- 
tered to the document registry. The mechanism is explained 
in ITI-42 transaction of the IHE-ITI TF, which is used in 
tandem with IHE-RAD TF in the imaging document shar- 
ing workflow. A document that has been registered in the 
registry will be visible to the entire HIE; thus, it is retrievable 
across various organizations in the HIE. If a document con- 
sumer invokes an ITI-18 transaction request to the registry, 
it can recognize if a new document has been submitted to 
the HIE and obtain the repository address from which the 
document can be retrieved. Subsequently, by invoking an 
ITI-43 transaction, the document consumer can fetch the 
document from the repository. As images are shared in the 
HIE in the form of manifest files, the imaging consumer part 
of the document consumer should properly parse a manifest 
file and retrieve the original image file from an address pro- 
vided by the imaging document source. 

The gateway provides a WADO interface for image re- 
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trieval. The WADO image retrieval mechanism is defined 
in RAD-55 transaction of the IHE-RAD TF. In this transac- 
tion, an imaging document consumer can obtain an image 
by accessing a certain HTTP URL. The consumer provides 
the necessary parameters, which at least include the study 
instance universal ID (UID), series instance UID, and object 
instance UID of the image, and appends these parameters 
to an HTTP GET query request. If the image can be found, 
a response is sent back to the consumer containing the re- 
quested image in DICOM or JPEG format. The consumer is 
responsible for extracting the image from the response and 
displays it on its interface according to its display mecha- 
nism. 

The imaging document sharing workflow also enlists other 
mechanisms of image retrieval. The imaging gateway cur- 
rently does not implement those mechanisms since XDS-I 
document retrieval via WADO suffices for the current setup. 
However, the gateway is designed to have sufficient flexibility 
to extend the image retrieval mechanisms it supports. 

2) Imaging gateway modules 

The imaging gateway application is built on top of Java En- 
terprise Edition 7. It is deployable as a binary in a Linux 
environment. The application is designed to be modular to 
ease future addition to its components and features. The fol- 
lowing modules have been developed to compose the entire 
imaging gateway application: 

1. Hospital information system (HIS) interface module, 

2. Image acquisition and processing module, 

3. Image retrieval module, 

4. HIE integration module. 

(1) HIS interface module 

This module manages the connectivity between the imaging 
gateway and the existing hospital information system. For 
the staging environment, the HIS application is represented 
with the OCS. The gateway publishes a RESTful Web service 
address that can be accessed by Gil Hospital OCS. The OCS 
initiates the imaging document sharing workflow by invok- 
ing an image sharing request to the web service address. The 
request contains patient information and additional meta- 
data. Upon receiving this request, the gateway will perform 
some validation and then pass the request to the image shar- 
ing queue. 

(2) Image acquisition and processing module 

This module pulls an image sharing request from the queue 
and performs image acquisition and processing. The image 
acquisition method can vary, depending on the interface that 
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is provided by the target PACS. The gateway is capable of 
switching between several acquisition methods that include 
standard DICOM Query/Retrieve and Store and non-stan- 
dard ones, such as File Transfer Protocol (FTP) access. After 
an image is acquired by the gateway, some processing will 
take place. The processing includes creation of a snapshot 
JPEG image that represents a single/multi frame DICOM 
image and creation of a key object selection (KOS) manifest 
that will be later submitted to the document repository. 

(3) Image retrieval module 

This module manages WADO HTTP endpoints that can 
be accessed by an imaging document consumer to retrieve 
an image. Two endpoints are provided: non- secure HTTP 
and secure HTTP with Secure Socket Layer (SSL) channel 
encryption. By providing a secure WADO endpoint, the 
gateway minimizes the possibility of man-in-the-middle at- 
tack and ensures that imaging data is encrypted and securely 
transmitted over the network transport channel. 

(4) HIE integration module 

This module handles the interactions or transactions be- 
tween the gateway and HIE. There are two primary types 
of transactions that are managed by this module. The first 
one is patient demographics queries (PDQ). This type of 
transaction is also referred to as ITI-21. In this transaction, 
the module requests the global patient ID that is used for 
the entire HIE and additional demographics data from the 
master patient index server. The master patient index keeps 
the map of local IDs and the corresponding global ID of a 
patient. It is capable of resolving a global patient ID given a 
local patient ID and vice versa. Local patient identification 
including a patient's demographic data is supplied by the 
OCS application in each facility by sending the proper HL7 
Admit Discharge Transfer (ADT) message to the designated 
port of the master patient index server. 

The demographics data received from the master patient 
index server is used in composing a RAD-68 request. No- 
ticeably, the other transaction is provide-and-register-imag- 
ing-document-set transaction or RAD-68. The module pe- 
riodically checks its index to find if there are image sets that 
have not been submitted to the document repository. If one 
or several image sets are found, the module will sequentially 
register all available sets to the document repository. Each 
set is associated with one KOS manifest file. This indicates 
that, for each registration of an image set, one KOS manifest 
file will be registered to the document repository. 



3. PACS-HIE Connectivity Testing in the Gil Hospital's 
Staging Environment 

As explained earlier, three facilities are designated in the 
staging environment. To test connectivity, each facility PACS 
was connected to one instance of the imaging gateway. This 
setup enables each gateway to operate independently. Ad- 
ditionally, having one gateway on each facility enables asym- 
metric imaging document sharing workflow initiation. Each 
facility can independently initiate the workflow from the 
entry system, which is represented by the OCS. 

Sample patient data were used in the test. For every test 
patient in each facility, the OCS sends a request to the gate- 
way to start the imaging document sharing workflow. After 
validating the request, the gateway handles the necessary 
logic to find patient identification in the HIE, processes im- 
ages acquired from PACS, generates image manifest file, and 
registers the manifest file to Gil Hospital HIE for XDS. To 
view images that correspond to a patient, an XDS viewer has 
been developed and used. It is run from the browser, thus 
minimizing additional software installation at the client side. 
The viewer can properly parse the manifest file and display 
the images in a set in sequence. 

Figure 3 shows three samples of image sets taken from 
computed tomography (CT), computed radiography (CR), 
and ultrasound (US) modalities. The image sets correspond 
to abdomen studies with 22 images, colon studies with 50 
images, and thyroid gland studies with 6 images, respec- 
tively. Samples are chosen from available population sets to 
represent variations in image sizes. For all images in each 
set, equivalent JPEG image caches are generated from the 
acquired DICOM files. By generating cache files, the gateway 
can immediately provide a representative image requested 
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by the viewer without conducting image preprocessing every 
time. As seen in the figure, the JPEG caches are significantly 
smaller in size compared to the original DICOM files, thus 
enabling the viewer to display images in a timely manner. 
For CT images, the average JPEG-DICOM ratio is 7.42%, the 
minimum ratio is 7.15%, and the maximum ratio is 7.62%. 
CR images have an average JPEG-DICOM ratio of 4.4% with 
a minimum ratio of 3.73% and a maximum ratio of 5.94%. 
Finally, US images correspond to an average JPEG-DICOM 
ratio of 12.07%, a minimum ratio of 4.84%, and a maximum 
ratio of 13.51%. These ratios are specific to the sample im- 
ages used in the tests and can vary for different examination 
images across different modalities. 

The DICOM image objects are loaded by the viewer by in- 
voking WADO calls. An insecure WADO call is channeled 
through HTTP while a secure WADO call uses HTTPS as 
the transport protocol. Figure 4 shows the average loading 
time of test images in JPEG format when loaded from both 
WADO HTTP and WADO HTTPS addresses. As shown in 
Figure 3, the generated JPEG images converge to a certain 
size for each modality. The average loading time is then de- 
termined by aggregating the loading time measures of each 
image in HTTP and HTTPS to obtain the statistical average. 
As seen in Figure 4, some performance penalty is incurred 
when image objects are loaded securely from their WADO 
HTTPS addresses. This is expected since the image objects 
have to be encrypted at the gateway side prior to transmis- 
sion over the network, and the decryption process should 
take place at the viewer side before the image objects are dis- 
played to the user. 

Another interesting finding in Figure 4 is the similarity of 
loading time for sample images in US and CT modalities de- 
spite the different average JPEG image sizes. The JPEG image 
samples from the US modality have an average size of 100.6 



kB, a minimum size of 87.7 kB, a maximum size of 113 kB, 
and a standard deviation of 5.21. On the contrary, the JPEG 
image samples from the CT modality have an average size 
of 38.15 kB, a minimum size of 36.76 kB, a maximum size 
of 39.16 kB, and a standard deviation of 0.73. The size of a 
TCP packet underlying both HTTP and HTTPS protocols is 
normally at 64 kB. This implies that each US image is frag- 
mented into two packets, whereas a CT image is transmitted 
as a single packet. Based on this implication, it can be argued 
that the transmission time did not differ significantly for 
one or two TCP packets in the network where the test was 
conducted. However, this argument cannot be generalized to 
other networks. Furthermore, it was also observed that when 
the number of packets grows significantly as exemplified by 
the CR images, the transmission time properly increases. 

In the current approach, the XDS-I gateway offloads DI- 
COM image processing tasks to the client side. A user action 
that changes the presentation of an image, such as changing 
image window level or zooming into an image, propels the 
DICOM image file download to the client side so that it can 
be processed by the viewer. Figure 5 shows the loading time 
measures for DICOM images with different sizes loaded by 
the viewer on Chrome3 1 and IE9 browsers that are installed 
on a Windows7 64-bit workstation with 3.2 GHz quad-core 
processor and 8 GB RAM. As seen in the figure, the browsers 
under test exhibited variations in performance. On average, 
Chrome was four times faster in each test when processing 
and loading the DICOM image file to be viewed by the user. 
Nonetheless, it is important to note that conducting image 
processing on the browser can be a suboptimal approach. 
For example, changing the window image level of a 16-bit 
channel DICOM image with a size of around 13 MB takes 
almost 6 seconds in Chrome31 and 23 seconds in IE9. Such 
loading time indicates degradation of serviceability that ne- 



160 -i 
140 
120 
100 

80 

60 

40 

20 
0 



□ 

□ 



HTTP 
HTTPS 
Av size 




r 600 



500 



400 cp 
n' 

I 0 

300 g 



200 



100 



0 



US CT CR 

Figure 4. Image loading time via Web Access to DICOM Persistent 
Objects calls. US: ultrasound, CT: computed tomogra- 
phy, CR: computed radiography. 



25 



20 



15 



10 



0 



E3 IE9 level 

H IE9 parsing 

□ IE9 download 

O Chrome31 level 

■ Chrome31 parsing 

■ Chrome31 download 



5 



8-bit 256 kB 1 6-bit 5,852 kB 1 6-bit 12,816 kB 

Figure 5. Digital Imaging and Communication in Medicine image 
loading time for a window image level adjustment task. 



298 www.e-hir.org 



http://dx.doi.org/10.4258/hir.2013.19A293 



J-J YR Healthcare Informatics Research 



XDS-I Gateway for Legacy PACS 



cessitates a revisit to the image processing approach. A dif- 
ferent approach can be devised, such as hybrid client-server 
image processing. However, this is beyond the scope of this 
article. 

III. Discussion 

In the testing, we successfully share images stored in all facil- 
ities to the HIE and the shared images were retrieved by an 
XDS viewer. In the staging environment created for testing, 
the gateway was deployed in each facility. It is reasonable to 
question the feasibility of deploying only a single gateway for 
all facilities. From our perspective, this is feasible but not in 
all cases. A single gateway fits the deployment setup better if 
there is only one or an integrated input mechanism for the 
imaging data sharing request. For example, if a portal that 
coordinates all facilities exists, input can be given from the 
portal to the gateway. The gateway will then be responsible 
for discovering a patient from the list of PACS it mediates 
and completing the whole imaging document sharing work- 
flow. 

Valente et al. [10] proposed a RESTful image gateway that 
provides image retrieval capability from multiple backend 
PACS. In their approach, images can be retrieved at study 
level, series level, or instance level, depending on the ser- 
vice address that is called by the Web service client. This 
approach eliminates the single instance image retrieval 
disadvantage incurred by WADO retrieval. By offering the 
capability to retrieve images in bulk, an imaging document 
consumer may constitute a better strategy for image display. 
Despite the benefit, this approach may suffer from future 
interoperability issue since the service definitions are non- 
standard. A more desirable route can be taken by imple- 
menting Supplement 161 of the DICOM specification, which 
outlines the mechanism for WADO retrieval via RESTful 
Web services. 

Security is also an important aspect in the gateway imple- 
mentation. We have addressed the security concern from 
the perspectives of node security, network security, and data 
security. The gateway application is hosted on an authenti- 
cated node. Communication between a node and PACS can 
occur only if each entity can recognize its counterpart as a 
legitimate peer. By mutually recognizing the peer, a node 
with obscure security is prevented from interacting with the 
system. To safeguard the gateway from network threats, the 
gateway node is placed in a private network. Access to this 
node from another facility is achievable via a VPN. Finally, 
data security is addressed by providing a Transmission Layer 
Security (TLS) channel for image data transmission that en- 



sures end-to-end data encryption, thus preventing an eaves- 
dropper from correctly interpreting the data while it is being 
transmitted over the network. 

Conflict of Interest 

No potential conflict of interest relevant to this article was 
reported. 

Acknowledgments 

This research was supported by the Project for Inducing 
Foreign Universities or Research Centers in Free Economic 
Zone administered by Ministry of Trade, Industry and En- 
ergy, Korea. 

References 

1. Kuperman GJ. Health-information exchange: why are 
we doing it, and what are we doing? J Am Med Inform 
Assoc 2011;18(5):678-82. 

2. Walker J, Pan E, Johnston D, Adler-Milstein J, Bates 
DW, Middleton B. The value of health care information 
exchange and interoperability. Health Aff (Millwood) 
2005;Suppl Web Exclusives:W5-10-W5-18. 

3. Choplin RH, Boehme JM 2nd, Maynard CD. Picture 
archiving and communication systems: an overview. 
Radiographics 1992;12(l):127-9. 

4. Huang HK, Taira RK. Infrastructure design of a picture 
archiving and communication system. AJR Am } Roent- 
genol 1992;158(4):743-9. 

5. Bidgood WD Jr, Horii SC. Introduction to the ACR-NE- 
MA DICOM standard. Radiographics 1992;12(2):345- 
55. 

6. Medical Imaging and Technology Alliance. The DICOM 
standard version 2011 [Internet]. Rosslyn (VA): Na- 
tional Electrical Manufacturers Association; c2013 [cited 
at 2013 Sep 5]. Available from: http://medical.nema.org/ 
standard.html. 

7. Main C, Moxham T, Wyatt JC, Kay J, Anderson R, Stein 
K. Computerised decision support systems in order 
communication for diagnostic, screening or monitor- 
ing test ordering: systematic reviews of the effects and 
cost-effectiveness of systems. Health Technol Assess 
2010;14(48):l-227. 

8. Park DK, Jung EY, Jeong BH, Moon BC, Kang HW, 
Tchah H, et al. Smart information system for Ga- 
chon University Gil Hospital. Healthc Inform Res 
2012;18(l):74-83. 



Vol.19 • No. 4 • December 2013 



www.e-hir.org 299 



Mikael Fernandus Simalango et al 



Healthcare Informatics Research 



9. Integrating Healthcare Enterprise. IHE Technical Frame- 
works [Internet]. Oak Brook (IL): Integrating Healthcare 
Enterprise; c2013 [cited at 2013 Sep 5]. Available from: 
http:// www.ihe.net/Technical_Frameworks/. 



10. Valente F, Viana-Ferreira C, Costa C, Oliveira JL. A REST- 
ful image gateway for multiple medical image repositories. 
IEEE Trans Inf Technol Biomed 2012;16(3):356-64. 



300 www.e-hir.org 



http://dx.doi.org/10.4258/hir.2013.19A293 



